fix(compose): Stop SentryTraced from reusing stale parent spans - #6057
Merged
Conversation
Fix the stale parent problem that causes spans from all SentryTraced instances for the entire app process to be dropped once the initial active transaction finishes. Prior to this commit, SentryTraced used process-wide composition locals to bind the transaction active whenever the first SentryTraced for an app process entered the composition, and to reuse it for all SentryTraced instances thereafter. That meant all SentryTraced spans for the entire app would be dropped for the lifetime of the app process once the initial transaction finished. Oof. This commit sets things right by having each SentryTraced composable request the current active transaction and update the generation of spans accordingly. Because we're no longer relying on a single transaction + parent span pair, SentryTraced now needs to manage the creation of possibly multiple parent span pairs, as the owning transaction updates. That logic lives in the new ParentSpans class.
0xadam-brown
force-pushed
the
fix/sentry-traced-stale-parent
branch
from
September 5, 2026 08:38
302c95b to
e508334
Compare
0xadam-brown
commented
Sep 5, 2026
📲 Install BuildsAndroid
|
0xadam-brown
commented
Sep 5, 2026
0xadam-brown
commented
Sep 5, 2026
0xadam-brown
marked this pull request as ready for review
September 5, 2026 08:46
0xadam-brown
requested review from
adinauer,
markushi,
romtsn and
runningcode
as code owners
September 5, 2026 08:46
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit e508334. Configure here.
Pass the captured start timestamp through the timestamp-aware span overload when creating shared SentryTraced parent spans. This keeps parent spans from starting after their child composition or render spans. Add regression coverage for parent span start ordering. Co-Authored-By: OpenAI GPT-5.5 <noreply@openai.com>
runningcode
reviewed
Sep 7, 2026
runningcode
left a comment
Contributor
There was a problem hiding this comment.
Looks good! I'll note that this is not a deep dive since I am not a compose expert. I added some nits and happy to discuss those if needed.
For my understanding, what are the units the benchmark you performed? and was it a macrobenchmark?
runningcode
approved these changes
Sep 7, 2026
9 tasks
9 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

📜 Description
PR fixes the stale parent problem that causes spans to be dropped from all SentryTraced instances for the entire app process after the initial active transaction finishes.
Prior to this PR, SentryTraced used process-wide composition locals to bind the transaction active whenever the first SentryTraced for an app process entered the composition, and to reuse it for all SentryTraced instances thereafter. That meant all SentryTraced spans for the entire app would be dropped for the lifetime of the app process once the initial transaction finished.
This PR sets things right by having each SentryTraced composable request the current active transaction and update the generation of spans accordingly.
Because we're no longer relying on a single transaction + parent span pair, SentryTraced now needs to manage the creation of possibly multiple parent span pairs, as the owning transaction updates. That logic lives in the new ParentSpans class.
💡 Motivation and Context
(See above.)
Measuring performance
Performance of SentryTraced is essentially unchanged, if not slightly better with the introduction of this PR. Expand below to see the details.
Details
I had my clanker run 8 time trials, comparing
mainagainst this PR.Key Timing Results
ui.composechild countComposeActivitychild set in the stock multi-screen flowui.composechild countComposeActivitybuttons_pageui.composeavg msComposeActivitybutton_nav_githubui.composeavg msComposeActivitybutton_dialog#2ui.composeavg msComposeActivitybuttons_pageui.composeavg msComposeActivitybutton_nav_githubui.composeavg msComposeActivitybutton_dialog#2ui.composeavg msComposeActivitybuttons_pageui.renderavg msComposeActivitynavhostui.renderavg msExecutive Summary
ui.composechild countComposeActivitychild spans in the stock flowbuttons_pageui.composeavg msbutton_nav_githubui.composeavg ms💚 How did you test it?
New unit tests + I had my clanker run manual tests for both correctness and performance against the Compose and Nav2 sample apps.
📝 Checklist
sendDefaultPIIis enabled.🔮 Next steps